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Abstract. Type-based amortised resource analysis following Hofmann and Jost — where 
resources are associated with individual elements of data structures and doled out to the 
programmer under a linear typing discipline — have been successful in providing concrete 
resource bounds for functional programs, with good support for inference. In this work 
we translate the idea of amortised resource analysis to imperative pointer-manipulating 
languages by embedding a logic of resources, based on the afhne intuitionistic Logic of 
Bunched Implications, within Separation Logic. The Separation Logic component allows 
us to assert the presence and shape of mutable data structures on the heap, while the 
resource component allows us to state the consumable resources associated with each 
member of the structure. 

We present the logic on a small imperative language, based on Java bytecode, with 
procedures and mutable heap. We have formalised the logic and its soundness property 
within the Coq proof assistant and extracted a certified verification condition generator. 
We also describe an proof search procedure that allows generated verification conditions to 
be discharged while using linear programming to infer consumable resource annotations. 

We demonstrate the logic on some examples, including proving the termination of in- 
place list reversal on lists with cyclic tails. 



1. Introduction 

Tarjan, in his paper introducing the concept of amortised complexity analysis [25], noted 
that the statement and proof of complexity bounds for operations on some data structures 
can be simplified if we think of the data structure as being able to store "credits" that 
are used up by later operations. By setting aside credit inside a data structure to be 
used by later operations, the cost of a sequence of operations can be amortised over time. 
In this paper, we propose a way to merge amortised complexity analysis with Separation 
Logic \19\ [23] to formalise some of these arguments and to simplify the specification and 
verification of resource-consuming pointer-manipulating programs. 

Separation Logic is built upon a notion of resources and their separation. The assertion 
A * B holds for some resource if it can be split into two separate resources that make A 
true and B true respectively. Resource separation enables local reasoning about mutation 
of resources; if the program mutates the resource associated with A, then we know that B 
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is still true on its separate resource. Usually Separation Logic uses mutable heaps as its 
notion of resource. In this paper, we combine heaps with consumable resources to reason 
about resource consumption as well as resource mutation. 

To see how Separation Logic-style reasoning about consumable resources is beneficial, 
consider the standard inductively defined list segment predicate from Separation Logic, 
augmented with an additional proposition R denoting the presence of a consumable resource 
for every element of the list: 

lseg(i?, = a; = y A emp 

V 3(i, z. \x d\ * [x "S* z\*- R*- lseg(2;, y) 



We will introduce the assertion logic properly in [Section 41 below. We can represent a heap 
H and a consumable resource r that satisfy this predicate graphically: 

null I 




R 



R 



R 



R 



So we have r,H \= lseg(i?, x, null), assuming x contains the address of the head of the list. 
Here r = R-R- R- R — we assume that consumable resources form a commutative monoid — 
and r represents the resource that is available for the program to use in the future. We can 
split H and r to separate out the head of the list with its associated resource: 

null 




R 



R 



This heap and resource satisfy ri ■ r2, Hi w H2 |= [x a] * [x "S* y] * R * lseg(i?, y, null), 
where Hi tb H2 = H , ri ■r2 = r and we assume that y contains the address of the b element. 
Now that we have separated out the head of the list and its associated consumable resource, 
we are free to mutate the heap Hi and consume the resource ri without affecting the tail 
of the list. So the program can move to a new state where the head of the list has been 
mutated to A and the associated resource has been consumed: 

null 




R 



R 



R 



We do not need to do anything special to reason that the tail of the list and its associated 
consumable resource are unaffected. 

The combined assertion about heap and consumable resource describes the current 
shape and contents of the heap and also the available resource that the program may 
consume in the future. By ensuring that, for every state in the program's execution, the 
resource consumed plus the resource available for consumption in the future is less than or 
equal to a predefined bound, we can ensure that the entire execution is resource bounded. 
This is the main assertion of soundness for our program logic in [Section 3.5[ We also treat 
a variant program logic that allows dynamic but fallible resource acquisition in [Section 3.61 

By intermixing resource assertions with Separation Logic assertions about the shapes 
of data structures, as we have done with the resource carrying Iseg predicate above, we can 
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specify amounts of resource that depend on the shape of data structures in memory. By the 
definition of Iseg, we know that the amount of resource available to the program is linearly 
proportional to the length of the list, without having to do any arithmetic reasoning about 
lengths of lists. In [Section 4.21 we describe some useful inductively defined predicates that 
maintain a close connection between shape and resources. 

The association of resources with parts of a data structure is exactly the banker's 
approach to amortised complexity analysis proposed by Tarjan. 

Our original inspiration for this work came from the work of Hofmann and Jost |15] on 
the automatic heap-space analysis of functional programs. Their analysis associates with 
every element of a data structure a permission to use a piece of resource (in their case, heap 
space). This resource is made available to the program when the data structure is decom- 
posed using pattern matching. When constructing part of a data structure, the required 
resources must be available. A linear type system is used to ensure that data structures 
carrying resources are not duplicated since this would entail duplication of consumable re- 
source. This scheme was later extended to imperative object-oriented languages \16\ 117]. 
but still using a type-based analysis. 

1.1. Contributions. We summarise the content and contributions of this work: 

• In [Section 31 we define a program logic that allows mixing of assertions about heap shapes 
and assertions about future consumable resources. Tying these together allows us to easily 
state resource properties in terms of the shapes of heap-based data structures, rather than 
in terms of extensional properties such as their size or contents. We have formalised the 
soundness proof of our program logic in the Coq proof assistant. 

• In [Section 41 we present a syntax for our assertion logic, based on a combination of Boolean 
Bunched Implications extended with pointer assertion primitives, as is usual for Separa- 
tion Logic, and affine intuitionistic Bunched Implications to declaratively state properties 
of the consumable resource available to a program. We also discuss several useful induc- 
tively defined predicates for this logic that demonstrate tight connections between heap 
shapes and resources. We also discuss the advantages and disadvantages of this tight 
connection. 

• In [Section "51 we define a restricted subset of the assertion logic that allows us to perform 
effective proof search to discharge verification conditions, while inferring resource anno- 
tations. A particular feature of the proof search procedure we describe is that, given loop 
invariants that specify only the the shape of data structures, we can infer the necessary 
consumable resource annotations. 

• In [Section "2] and [Section "61 we demonstrate the logic on some examples, showing how 
a mixture of amortised resource analysis and Separation Logic can be used to simplify 
resource-aware specifications, deal with relatively complex pointer manipulation and to 
prove termination in the presence of cyclic structures in the heap. 

1.2. Differences to previously published versions. This paper is a revised and ex- 
panded version of the ESOP 2010 conference version [5j. Additional explanation has been 
provided and [Section 3.6[ has been added on a variant program logic accounting for dynamic 
resource acquisition. [Section "41 has been expanded with more examples of inductively de- 
fined predicates tightly integrating shape and resource properties, and a discussion of the 
disadvantages of this integration. [Section 5l on automated verification and proof search has 
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been refined for clarity and to better match the implementation. We have also included the 
merge-sort example in [Section 2.21 from an invited TGC 2010 paper [2]. 

2. Motivating Examples 

The example we gave in the lintroductioni where a program iterates through a list consuming 
resources as it proceeds, only demonstrates an extremely simple, albeit common, pattern. 
In this section, we give two more complex examples that serve to highlight the advantages of 
the amortised approach to specifying and verifying resource bounds. The first example, in 
[Section 2.11 demonstrates how the integrated description of available consumable resources 
and heap structure helps with specification. The second example, in [Section 2.2( shows 
how the amortised approach simplifies the problem of verifying the resource consumption 
of a pointer manipulating program. This example also shows a weakness of maintaining a 
tight connection between heap shape and consumable resources, which we discuss further 
in [Section 4.31 

In each case we attempt to demonstrate how amortised reasoning is easier than the 
traditional approach of keeping a global counter for consumed resources as a "ghost" variable 
in the logic. 

2.1. Functional Queues. We consider so-called functional queues [l8l[8], where a queue 
is represented by a pair of lists. This example is a standard one for introducing amortised 
complexity analysis [21] . We verify an imperative implementation that performs mutations 
in-place on the underlying lists. The point of this example is to see how the amortised 
technique simplifies the specifications of the procedures operating on this data structure. 




null 



The top list represents the head of the queue, while the bottom list represents the tail of 
the queue in reverse. This structure represents the queue [a, b, c, d, f , e]. When we enqueue 
a new element, we add it to the head of the bottom list. To dequeue an element, we remove 
it from the head of the top list. If the top list is empty, then we reverse the bottom list 
and change the top pointer to point to it, changing the bottom pointer to point to null, 
representing the empty list. 

When determining the complexity of these operations, it is obvious that the enqueue 
operation is constant time, but the dequeue operation either takes constant time if the top 
list is empty, or takes time linear in the size of the bottom list in order to perform the 
reversal. If we were to account for resource usage by maintaining a global counter then 
we would have to expose the lengths of the two lists in specification of the enqueue and 
dequeue instructions. So we would need a predicate queue(x, h,t) to state that x points to 
a queue with a head and tail lists of lengths h and t respectively. The operations would 
have the specifications (written as Hoare triples): 

Vri. {queue{x, h,t) A rc = ri} enqueue {queue(x, h,t + 1) a rc = ri + R} 

Vri. {queue(x, 0, t) A Tc = ri} dequeue {queue(2;, t — 1, 0) a Tc = ri + (1 + 

Vri. {queue{x, h + l,t) A Vc = ri} dequeue {queue{x, h,t) a Vc = ri + R} 
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where rc is a ghost variable counting the total amount of resource consumed by the program, 
and R is the amount of resource required to perform a single list node manipulation. The 
dotted minus t — 1 denotes the predecessor operation on natural numbers. Note that we 
have had to give two specifications for dequeue for the cases when the head list is empty 
and when the head list has an element. The accounting for the sizes of the internals of the 
queue data structure is of no interest to clients of this data structure. These specifications 
complicate clients' reasoning when using these queues. 

Using amortised analysis, this specification can be drastically simplified. We associate 
a single piece of resource with each element of the tail list so that when we come to reverse 
the list we have the necessary resource available to reverse each list element. The queue 
predicate is therefore: 

queue(x) = By, z. [x y] * [x * lseg(e, y, null) * lseg(i?, z, null) 

where Iseg is the resource-carrying list predicate given above and e is the unit of the con- 
sumable resource monoid, representing no resource. The list holding the head of the queue 
has no resource associated with every element, while the list holding the tail of the queue 
does have a resource associated with every element, waiting to pay for the list reversal when 
it occurs. Diagrammatically, a queue with associated resources looks like this: 




null 



R R 



The specifications of the operations now becomes straightforward: 

{queue(2;) * R * i2}enqueue{queue(x)} {queue(x) * i?}dequeue{queue(2;)} 

To enqueue an element, we require two elements of resource: one to add the new element 
to the tail list, and one to "store" in the list so that we may use it for a future reversal 
operation. To dequeue an element, we require a single element of resource to remove an 
element from a list. If a list reversal is required then it is paid for by the resources previously 
required by enqueue. 

Once we have set the specification of queues to store one element of resource for every 
node in the tail list, we can use the resource annotation inference procedure presented in 
[Section "Sl to generate the resource parts of the enqueue and dequeue specifications. 



2.2. Merge-sort Inner Loop. We now describe a more complicated list manipulating 
program that shows the benefits of the amortised approach for verification. This example 
demonstrates the combination of reasonably complex pointer manipulation with resource 
reasoning. Most of the technical details arise from dealing with the heap-shape behaviour 
of the program; the resource bounds simply drop out thanks to the inference of resource 
annotations. 

Consider the Java method declaration merge Inner shown in [Figure 1 that describes 



the inner loop of an in-place merge sort algorithm for linked list^. The method takes two 
arguments: list, a reference to the head node of a linked list; and k, an integer. The 
integer argument dictates the sizes of the sublists that the method will be merging in this 



^Adapted from C code: [http : //www . chiaxk . greenend . org . uk/~ sgtatham/ algorithms/list sort . html | 
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public Static Node mergelnner (Node list, int k) { 
Node p = list; 

Node tail = null; 

list = null; 

while (p ! = null) { 
Node q = p; 

for (int i = 0; i < k; i++) { 
q = q.next; 
if (q == null) break; 

> 

Node pstop = q; 
int qsize = k; 

while (p != pstop I I (qsize > && q != null)) { 
Node e; 

if (p == pstop) { 
e = q; 
q = q.next; 
qsize — ; 

y else if (qsize ==0 II q == null) { 

e = p; 

p = p. next; 
} else if (p. data <= q.data) { 

e = p; 

p = p. next; 
} else { 

e = q; // perform swap 

q = q.next; 

qsize — ; 

} 

if (tail != null) tail. next = e; 
else list = e; 

tail = e; 

} 

p = q; 

} 

if (tail == null) return null; else tail. next = null; 
return list; 

} 

Figure 1: Inner loop of an in-place linked- list merge sort 
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pass. The method steps through the hst 2*k elements at a time, merging the two subhsts 
of length k each time. The outer loop does the 2*k stepping, and the inner loop does the 
merging. To accomplish a full merge sort, mergelnner would be called log2 n times with 
doubling k, where n is the length of the list. 

Assume that we wish to account for the number of swapping operations performed by 
this method, i.e. the number of times that the fourth branch of the if statement in the 
inner loop is executed. We accomplish this in our implementation by inserting a special 
consume instruction at this point. 

The pre- and post-conditions of the method are as follows: 

Pre (merge Inner) : list =|= null a (lseg(x, list, null) * R^) 
Post (mergelnner) : lseg(0, retval, nit//) 

The precondition states that the first argument points to a list segment ending with 
null, with X amount of resource associated with every element of the list, and y amount 
of additional resource that may be used. The actual values of x and y will be inferred by a 
linear program solver. The condition list =|= null is a safety condition required to prevent 
a null pointer exception. 

The outer loop in the method needs a disjunctive invariant corresponding to whether 
this is the first iteration or a later iteration. 

(lseg(oi, list, tail) * [tail "h^*?] * [tail 1^^?] * lseg(o2,p, null) * R°^) 
V ((list = null A tail = null) * lseg(o4,p, null) * R°^) 

The first disjunct is used on normal iterations of loop: the variable list points to the 
list that has been processed so far, ending at tail; and p points to the remainder of the list 
that is to be processed. We have annotated these lists with the resource variables oi and 
02 that will contain the resources associated with each element of these lists. The second 
disjunct covers the case of the first iteration, when list and tail are null and p points 
to the complete list to be processed. The resource annotation 04 will be filled in with the 
amount of resource that is required for every element of the list to be processed. As one 
might expect, this will be equal to the value of x, the amount of resource required by the 
precondition of the method. 

Moving on, we consider the first inner loop that advances the pointer q by k elements 
forward, thus splitting the list ahead of p into a k-element segment and the rest of the list. 
The next loop will merge the first k-element segment with the k-element prefix of the second 
segment. It is convenient for our implementation to split out this inner loop into another 
methoc0, with the following signature: 
public static Node advance (Node 1, int k) 

The argument 1 points to a linked list, and the method will advance k elements through 
the list (or until the end) and return a pointer to the split point. The specification of this 
method is: 

Pre(advance) : lseg(ao, 1, nuZ/) 

Post(advance) : lseg(ao, 1, retval) * lseg(ao, retval, nu//) 

^This is because our implementation works on unstructured JVM-like bytecode, and so cannot easily 
apply Separation Logic's frame rule to modularly reason about the loop. Using a separate method allows 
application of the frame rule. See [Remark 3.21 
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Again, we have left the resource annotation on the elements of the list as a variable ao, 
to be filled in by the linear solver. The appearance of the same variable in the pre- and 
post-condition implies that we expect this resource to be preserved by the method. The 
fact that we have had to explicitly mention the resources that must be preserved points to 
a limitation of the amortised method as we present it here. We discuss this issue further in 
[Section 4.31 

Proceeding though our main method, the invariant of the inner loop is as follows, again 
as two disjuncts according to whether it is the first or later iteration of the outer loop: 

(lseg(ii, list, tail) * [tail "S*?] * [tail 1^^?] 

* Iseg(i2, P, pstop) * Iseg(i3, q, null) * R}*) 
V ((list = null A tail = null) * Iseg(i5, p, pstop) * lseg(ig, q, null) * i?*'') 

The first part of each disjunct is as before, stating that list to tail contains the part of list 
that has been processed. Since we have now split the remainder of the list into two pieces 
we have two separate list segments referenced by p and q pointing to the parts of the list 
that are to be merged. The resource meta-variable ii will indicate the amount of resource 
associated with the list that has been processed; 12 and is are the amount of resource 
associated with the "left-hand" pending list; and is and i4 are the resource associated with 
the "right-hand" pending list. 

At the end of the method, we null terminate the list and return. A superfluous null 
check on this is required for our tool to prove memory safety. The fact that this is non- 
null relies on the execution of the inner loop at least once, which requires that A; > 0. This 
fact is not expressible in the logic of the implementation described in [Section 5[ 

Running this example through our implementation produces the solution x = 1, y = 
for the precondition's resource annotations. This indicates that the input list needs to 
contain one element of resource for every list element. For the outer loop's invariant, we 
obtain 02 = 04 = 1 and all the others are 0. This indicates that the list we have processed has 
had all its resources consumed, while the list remaining to be processed still has associated 
resources. This is as expected for a loop iterating through a list. The specification of 
advance is completed by inferring oq = 1, indicating that advance preserves the resources 
associated with the list. Finally the inner loop's invariant has ^2 = is = is = ie = 1 and 
all others 0, indicating that the two list segments that are remaining to be processed have 
associated resources, while the processed segments do not. 

2.2.1. Comparisons to other techniques. Though we have had to work to supply the loop 
invariants for our implementation, we note that these invariants may be inferred by other 
tools, for example [6j, and the resource variables automatically inserted using the procedure 
outlined in [Section 51 The key to the amortised approach is the tight connection between 
shape invariants, which is a complex but well-studied problem, and resource consumption. 

Most other techniques for resource usage analysis that handle data structures do so by 
considering the sizes of the structures. The SPEED system of Gulwani et al. [13] can infer 
resource bounds for programs manipulating heap-based data structures, but only when these 
data structures are manipulated through abstract interfaces. The specifications for these 
abstract interfaces record the effect of the operations on the size of the data structure. Thus, 
the technique is unable to cope with the kind of program that we have presented above that 
uses direct pointer manipulation. Nevertheless, Gulwani et al. report impressive results on 
real-world Microsoft product code. 
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The COSTA system pLj can deal with some uses of direct pointer manipulation, but 
accounts for the sizes of heap-based data structures by counting the length of the longest 
path from a given reference. Thus, it cannot deal with programs that demonstrate sharing 
on the heap; the Java method described above has, in its inner loop, three pointers all 
pointing to the same list. 

One might also use Separation Logic to deal with sharing on the heap, and add informa- 
tion on the sizes of heap-based data structures to account for resource usage. So one would 
have a predicate lseg"(j;,y) that describes a list segment of length n from x to y, along 
with a ghost variable to track resource consumption as discussed in [Section 2.11 We argue 
that the amortised approach described here is simpler due to the differences in reasoning 
between the global property of the length of a whole list, and the local property of each 
list element having an associated amount of resource to be used. For example, consider the 
specification of the advance method using sized structures: 

Pre(advance) : \seg^{l, null) 

Post (advance) : 3ni,n2. ni + n2 = n a (Iseg"^ (1, retval) * Iseg"^ (retval, nuZ/)) 

We have had to introduce two existential variables indicating the sizes of the lists returned 
by the method. These additional values have to then be related back to the length of the 
original list by the calling method, and thence to the resource consumption, requiring non- 
straightforward arithmetic reasoning. The amortised approach exploits the shape-reasoning 
already present in Separation Logic to account for resources. 

3. A Program Logic for Heap and Resources 

We now describe a simple programming language and a consumable-resource-aware logic for 
it. We define a "shallow" program logic where we treat pre- and post-conditions and pro- 



gram assertions as arbitrary predicates over heaps and consumable resources. In [Section 4[ 

we will layer on top of this a "deep" assertion logic where predicates are actually Separation 
Logic formulae augmented with atomic resource propositions. 

At the lend of this section! we consider a variant system that allows dynamic but fallible 
resource acquisition as well as resource consumption. 

The development in this section has been formalised within the Coq proof assistant; thus 
the shallow embedding makes use of Coq's own logic as the assertion logic. We also make 
minor use of Coq's dependent types. ILemma 3.11 and [Theorem 3.31 establishing the sound- 
ness of the program logic have been mechanically verified within Coq, as have ILemma 3.5l 
and lTheorem 3.6] establishing soundness for the dynamic resource acquisition variant. 

3.1. Semantic Domains. Assume an infinite set A of memory addresses. We model heaps 
as finite partial maps EI = (A x F) -^fin V, where F ranges over field names and Y = A_l -I- Z 
represents the values that programs can directly manipulate: possibly null addresses and 
integers. We write dom{H) for the domain of a heap and Hi^H2 for heaps with disjoint 
domains; Hi i±i H2 denotes union of heaps with disjoint domains. 

Consumable resources are represented as elements of an ordered monoid (7^, E,-,e), 
where e is the least element. Example consumable resources include (N, ^, 0) or (Q^*^, ^ 
, -l-,0) for representing a single resource that is consumed (e.g. time or space), or multisets 
for representing multiple named resources that may be consumed independently. The or- 
dering on consumable resources is used to allow weakening in our assertion logic: we allow 
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the asserter to assert that more resources are required by the program than are actually 
needed. 

As is standard in the semantics of substructural logics [23], we make use of a ternary 
relation to describe the combination of separate entities. In our case, the entities are pairs 
of heaps and consumable resources: 

Rxyz 4» Hi#H2 A Hi ti) H2 = H3 A ri ■ r2 ^ 

where X = {Hi,ri),y = {H2,r2),z = (i?3,r3) 

We extend the order on resources to pairs of heaps and resources by {Hi,ri) E {H2,r2) iff 
Hi = H2 and ri E r2. 



3.2. A Little Virtual Machine. The programming language we treat is a simple stack- 
based virtual machine, similar to Java bytecode. We have removed the class-based object 
system and virtual methods, but retained mutable heap and procedures. There are two 
types: int and ref , corresponding to the two kinds of values in V. We assume a set P 9 pname 
of procedure names, where a procedure's name also determines its list of argument types 
and its return type. Programs are organised into a finite set of procedures, indexed by their 
name and individually consisting of lists of instructions from the following collection: 

L ::= iconst z \ ibinop op \ pop | load n | store n \ aconst_null 

I binarycmp cmp offset \ unarycmp cmp offset \ ifnull offset \ goto offset 

I new desc \ getfield fnm \ putfield fnm \ free desc \ consume r 

I return | call pname 

These instructions — apart from consume — are standard, so we only briefly explain them. 
Inside each activation frame, the virtual machine maintains an operand stack and a collec- 
tion of local variables, both of which contain values from the semantic domain V. Local 
variables are indexed by natural numbers. The instructions in the first two lines of the 
list perform the standard operations with the operand stack, local variables and program 
counter. The third line includes instructions that allocate, free and manipulate structures 
stored in the heap. The instruction consume r consumes the resource r. The desc argument 
to new and free describes the structure to be created on the heap by the fields and their 
types. The fourth line contains the procedure call and return instructions that manipulate 
the stack of activation frames. 

Individual activation frames are tuples {code, S, L, pc} e Frm consisting of the list of 
instructions from the procedure being executed, the operand stack and local variables, and 
the program counter. The first two lines of instructions that we gave above only operate 
within a single activation frame and have no effect on the heap or consumable resources, so 

we give their semantics as a small-step relation between frames: c Frm x Frm defined 
in Figure 2 The rules make use of semantic interpretations {op} and [cmp]] of binary 
operations and binary relations on integers. 

The third line of instructions contains those that manipulate the heap and consume 
resources. Their small-step operational semantics is modelled by a relation -^^^ c Frm x 
M X Frm x H x 7^, which relates the before and after activation frames and heaps, and 
states the consumable resource consumed by this step. The rules defining this relation are 



given in Figure 3 The rules for the instructions new and free take a parameter desc. This 



parameter describes the fields and their types for the object to be allocated or deallocated. 
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For a description desc = (/nm^ : ri, ...,fnmj^ : r„), we have written H[a i— > desc] to denote a 
heap updated with {a^fnm^) ^ default{Ti), where default{\r\t) = and default{ref) = null. 
For the free instruction, H\(a, desc) denotes the removal of all elements with keys {a,fnmj^) 
in H. 



code[pc] = iconst z 
{code, S, L, pc} {code, z :: S, L, pc + 1) 

code[pc] = ibinop op 
{code, z\ :: Z2 S, L, pc} {code, ([[op| zi Z2) ■■ S, L, pc + 1) 

code[pc] = pop code[pc] = load n L[n] = v 

{code, z :: S, L, pc} {code, S, L, pc + 1) {code, S, L, pc} {code, v :: S, L, pc + 1) 

code [pc] = store n 
{code, V :: S, L, pc} {code, S, L[n v],pc + 1) 

code[pc] = aconst_null 

{code, S, L, pc} {code, null :: S, L, pc + 1) 

code[pc] = binarycmp cmp offset z\ \cmp\ Z2 
{code, z\ .: Z2 S, L, pc} {code, S, L, offset} 

cod( [pc] = binarycmp cnip ojjsel ^{'-1 {'''''''Wl ^2) 
{code, z\ :: Z2 " •S', L, pc} {code, S, L, pc + 1) 

code[pc] = unarycmp cmp offset z \cmp\ 
{code, z .: S, L, pc} {code, S, L, offset} 

code[pc] = unarycmp cmp offset -^{z {cmp} 0) 
{code, z :: S, L, pc} {code, S, L, pc + 1) 

code[pc] = ifnull offset a = null code[pc] = ifnull offset a =|= null 

{code, a :: S, L, pc} {code, S, L, offset} {code, a :: S, L, pc} {code, S, L, pc + 1) 

code[pc] = goto offset 

{code, S, L, pc} {code, S, L, offset} 

Figure 2: Intra-frame Operational Semantics Rules 
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code[pc] = new desc {\ffnm. {a,fnm) ^ H) 
{code, S, L, pc}, H {code, a :: S, L, pc + 1), H[a desc],e 

code[pc] = getfield fnm H[a,fnm] = v 
{code, a :: S, L, pc}, H -'^ {code,v :: S, L, pc + 1), H, e 

code [pc] = putf ield fnm 

{code, a :: V :: S, L, pc}, H {code, S, L, pc + 1), H[{a,fnm) v],e 

code[pc] = free desc 
{code, a :: S, L, pc}, H -'^ {code, S, L, pc + 1), H\{a, desc}, e 

code[pc] = consume r 

{code, S, L, pc}, H {code, S, L, pc + 1), H, r 

Figure 3: Heap and Resource Mutating Operational Semantics Rules 

f^f f,H^f',H',r, 
{r, H, f :: fs} ^ {r, H, f :: fs} {r, H, f :: fs} ^ {r • r„ H' , f :: fs} 

code[pc] = return 

{r, H, {code, v :: S, L, pc} :: {code' , S', L', pc'} :: fs} (r, H, {code' , v :: S', L', pc'} :: fs} 

code[pc] = call pname prg[pname] = code' 
{r, H, {code, args -H- S, L, pc} :: fs} {r, H, {code' , [], "^args^ ,0} :: {code, S, L, pc + 1) :: fs} 

Figure 4: Small-step Operational Semantics Rules 

Note that all the rules in the relation apart from the consume instruction consume 
no resources: e is the identity element of our resource monoid. 

A state of the full virtual machine is a tuple {r, H, fs} 6 State, where r is the resource 
consumed to this point, h is the current heap, and fs is a list of activation frames. The small- 
step operational semantics of the full machine for some program prg is given by a relation 

c State X State which incorporates the and -^^^ relations and also describes how 
the call and return instructions manipulate the stack of activation frames. The rules defining 
this relation are presented in [Figure 4[ In the rule for the instruction call, the operation -H- 
denotes list concatenation, [] denotes the empty list and ^ denotes the translation of a 
list to a finite map from natural numbers in the obvious way. 

Finally, we use the predicate s [ H,r,v to indicate when a return instruction is to be 
executed and there is only one activation frame on the stack. In this case execution of the 
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program terminates. The H, r and v are the final heap, the total consumed resources and 
the return value of the program respectively. 



3.3. Assertions. Every procedure pname in the program is annotated with a precondi- 
tion and a post-condition. To allow for variables that are universally quantified over both 
the pre- and post-condition we make use of Coq's dependent types to augment procedure 
specifications with a specific "environment" type. A procedure specification is a dependent 
triple: 

<E : Type, PcExV*xHx7^,QcExV*xE[x7^xV> 
Preconditions P are predicates over E x V* x H x 7^: environments, lists of arguments to 
the procedure and the heap and available resource at the start of the procedure's execution. 
Post-conditions are predicates over ExV*xEIx7^xV: environments, argument lists and 
the heap, remaining consumable resource and return value. 

Intermediate assertions in our program logic are predicates over ExV*x]HIx7^xV*x 
(N ^ V): environments, argument lists, the heap, remaining consumable resource and the 
current operand stack and local variable store. Intermediate assertions are the assertions 
that are attached to every instruction in the body of a procedure by our program logic and 
specify a sufficient precondition for safely executing that instruction and all of its successors. 

Note that each of the three different types of assertions talks about the remaining 
consumable resources available to the program, not the resources that have already been 
consumed. 



3.4. Program Logic. A proof that a given procedure's implementation code matches its 
specification (E, P, Q} consists of a map C from instruction offsets in code to assertions such 
that: 

(1) Every instruction's assertion is suitable for that instruction: for every instruction offset 
i in code, there exists an assertion A such that C \-q {A} =^ i:code[i], and C[i] implies 
A. Figure 5 gives the definition of the judgement C \-q {A} =^ i:i for a selected subset 
of the instructions t. The post-condition Q is used for the case of the return instruction. 
We explain the definition of this judgement in more detail below. 

(2) The precondition implies the assertion for the first instruction: for all environments 
env 6 E, arguments args, heaps H and consumable resources r, we have 

P(e, args,H, r) =^ C[0](env, args, H, r, [], '^args^) 

where [] denotes the empty operand stack, and ^ maps lists of values to finite maps 



from naturals to values, as in the operational semantics in Figure 4 



When [condition II holds, we write this as C |— code : Q, indicating that the procedure 
implementation code has a valid proof C for the post-condition Q. 

The rules in [Figure 5 are an illustrative subset of the rules of the program logic. The 
rule for iconst merely states that the precondition for executing this instruction is the 
precondition of the next instruction with the specified integer pushed on to the stack. The 
rules for most of the other intra-frame, non-mutating instructions are similar. Slightly 
different are the rules for the conditional instructions, for example ifnull; these make use of 
logical conjunction to make sure that both possible outcomes of the conditional have their 
preconditions satisfied. 
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C \-Q {\{env, args, r, H, S, L). C[i + l]{env, args, r, H, z .: S, L)} ^ i:iconst z 

X(env, args, r, H, S, L). 

\/a,S'.S = a:: S' ^ . „ 

\-0 \ / I 77 ^r- -11/ TT ni T\\ r ^ zritnull n 

^ (a =1= null =^ C[i + l\{env, args,r,H,b ,L))a 

(a = null =^ C[n](enu, args, r, H, S', L)) 



X{env, args,r, H, S, L). 
ya,v,S'. 
C hQ \ S = a :: V :: S' A 

{a,fnm) e Ha 

C[i + l]{env, args,r, H[{a,fnm) v],S',L) 



zrputfield fnm 



X{env, args.r. H. S. L). 

3r'. Tc • r' E r A C\i + l\{env, args, r' , H, S, L) 



zxonsume Tc 



\{env, args, r, H, S, L). 

\iargs' S'.S = args' ^ S' ^ 
3env' eEp,{Hi,ri),(H2,r2). 
R{Huri){H2,r2){H,r)A 
C \-Q ■{ Pp(env',args',Hi,ri)A 
yv,{H[,r[). 

Qp{env' , args' , H[,r[,v) =^ 
C[i + l]{env, args' , r'l ■ r2, w H2, v :: S', L) 



zxall p 



C l-Q {\{env, args,r,H,S,L).\lv,S' . S = v :: S' ^ Q{env, args,r,H,v)] =^ z:return 



Figure 5: Program Logic Rules (Extract) 



The rules for putfield and consume demonstrate heap and consumable resource con- 
sumption respectively. For putfield, the heap is judged to be satisfactory if it contains the 
address and field that are to be mutated. For resource consumption, we must "subtract" 
the consumed resource from the current resource that has been supplied. If the desired 
resource is not present then this instruction's precondition will not hold. 

The rule for the call instruction demonstrates how the heap and the consumable re- 
sources are dealt with similarly for the purposes of a frame rule. The current heap and 
consumable resources are split into two parts {Hi,ri) and {H2,r2), with the first part be- 
ing handed off to the callee for it to be mutated. Finally, the precondition of the return 
instruction is directly derived from the post-condition of the current procedure. 



3.5. Soundness. Soundness for the program logic is stated as the preservation of a safety 
invariant by every step of the virtual machine. Wc define safety for activation frames, frame 
stacks and whole machine states, each building on the last. 
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We say that an activation frame is safe if there is a proof for the code being executed 
in the frame such that the requirements of the next instruction to be executed are satisfied. 
Formally, a frame / = {code, S, L, pc) is safe for environment env 6 E, arguments args, heap 
H, resource r and post-condition Q, written safeFrame(env, f, H,r, args,Q) i5 

(1) There exists a certificate C such that C \- code : Q; 

(2) C[pc] exists and C[pc]{env, args,r, H, S, L) holds. 

Safety of activation frames is preserved by steps in the virtual machine: 
Lemma 3.1 (Intra- frame safety preservation). 



(a) safeFrame ( env , f, Hi, r, args , Q) 

(b) Hii^H2 and Hi w H2 = H 

(c) f,H^f',H',r, 

then there exists H[ and r' such that 

(a) H[#H2 and H[ w H2 = H' 

(b) Tc ■ r' E r 

(c) safePrame{env, f, H[,r', args, Q). 

The second part of this lemma states that if we take a step that mutates the heap or 
consumes some resource, and the activation frame has been certified as safe for a sub-part 
of the heap, then the rest of the heap — H2 — is unaffected by a single step of execution in 
this activation frame, and the new state of the activation frame is safe for the mutated heap 
and new amount of consumable resources. 

Remark 3.2. We pause for a moment to consider the relationship between our program 
logic and traditional Separation Logic. The second part of the previous lemma effectively 
states that execution steps for mutating instructions are local: for any other piece of heap 
that is present but not mentioned in its precondition, the execution of a mutating instruction 
will not affect it. This is usually expressed in Separation Logic by the frame rule that states 
if we know that {P}C{Q} holds, then {P*R}C{Q*R} holds for any other resource assertion 
R. We do not have an explicit frame rule in our program logic; application of the rule is 
implicit in the rule for the call instruction (so, conflatingly, the frame rule is applied for 
new activation frames). We do not have access to the frame rule in order to modularly 
reason about the internals of each procedure, e.g. local reasoning about individual loops. 
This is partially a consequence of the unstructured nature of the bytecode that we are 
working with. It has not been a hindrance in small examples that we have verified so far, 
but may well become so in larger procedures with multiple loops that need invariants — see 
ISection 2.21 for an example. In such cases it may be useful to layer a hierarchical structure, 
matching the loops or other sub-program structure, on top of the unstructured bytecode in 
order to apply frame rules and facilitate local reasoning inside procedures. 



(1) 




(2) 



In this definition, and all the later ones in this section, we have omitted necessary assertions about 
well-typedness of the stack, local variables and the heap because they would only clutter our presentation. 
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We have now handled all the instructions except the call and return instructions that 
create and destroy activation frames. To state soundness of our program logic for these we 
need to define what it means for a stack of activation frames to be safe. Intuitively, a stack of 
activation frames is a bridge between the overall arguments args^^p and post-condition Qtop 
for the program and the arguments argSf.^^ and post-condition Qcur for the current activa- 
tion frame, with respect to the current heap H and available consumable resources r, such 
that, when the current activation frame finishes, its calling frame on the top of the stack is 
safe. We write this as safeStack^^^^ -^^^^ {fs, H, r, envcur, args^^^, Qcur, envtop, argst^p, Qtop)- 
The types Ec«r and E^p refer to the environment types for the current and top-level pro- 
cedures respectively, and envcur ^ '^cur-, envtop e ^top are the specific elements being used. 

Accordingly, we say that the empty frame stack is safe when r = e, H = emp, enVcur = 
envtop, o-W^cur = (^W^top ^'^d Qcur = Qtop- A non-empty frame stack /s = {code, S, L, pc} :: 
fs' is safe when there exist (Hi,ri), (H2,r2), env, args, Q and C, A such that: 

(1) R{H,,r,){H2,r2){H,ry, 

(2) The code is certified: C \- code : Q; 

(3) The next instruction to be executed has precondition A: C[pc] = A; 

(4) When the callee returns, the instruction's precondition will be satisfied: for all v 6 
Y,H2,r'2 such that H2#Hi and Qcuri^nvcur, argScur, ^'Ij^'z^''^) holds, A( env, args, r'2 ■ 
ri, H2 w Hi,v :: S,L) holds as well. 

(5) The rest of the frame stack fs will be safe when this activation frame returns: 
safeStack{fs,H2,r2, env, args,Q, envtop, args ^^p, Qtop) - 

Note how the safeStack predicate divides up the heap and consumable resource between the 
activation frames on the call stack; each frame hands a piece of its heap and consumable 
resource off to its callees to use. This mirrors the formulation of the rule for call in the 



program logic in Figure 5 



Finally, we say that a state s = (tc, H,fs)> is safe for environment env, arguments args, 
post-condition Q and maximum resource rmax, written safeState{s, env, args, Q,r max)-, if: 

(1) there exists an r future such that Tc • r future E rmax', and also 

(2) r future and H split into {Hi,ri) and {H2,r2), i.e. R{Hi,ri){H2,r2){H,rjuture)\ 

(3) there exists at least one activation frame: fs = f :: fs' and environment env cur, argu- 
ments argScur and post-condition Qcur', such that 

(4) safeFrame (/, Hi 

(5) safeStack{fs,H2,r2, env cur, args cur, Qcur, env, args,Q). 

The key point in the definition of safeState is that the assertions of the program logic talk 
about the resources that will be consumed in the future of the program's execution. Safety 
for a state says that when we combine the future resource requirements rfy^ture with resources 
that have been consumed in the past, rc, then the total is less than the total resources r^ax 
that are allowed for the execution. 

Theorem 3.3 (Soundness). Assume that all the procedures in prg match their specifications. 

(1) // 

(a) safeState{s, env, args, Q,rmax); md 

(b) s ^ s' 

then safeState{s' , env, args,Q,rmax)- 

(2) // safeState{s, 

env, args, Q,r max) and s J, H,r,v, then there exists an r' such that 
Q{env, args, H,r' ,v) and r - r' ^ rmax- 
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In the halting case in this theorem, the existentially quantified resource r' indicates the 
resources that the program still had available at the end of its execution. We are also 
guaranteed that when the program halts, the total resource that it has consumed will be 
less than the fixed maximum v^aax that we have set, and moreover, bv litem II of the theorem, 
this bound has been observed at every step of the computation. 

Remark 3.4. Though we assumed it above, the proof of soundness of the program logic does 
not require that the monoid of resources is commutative. This opens the way to considering 
non-commutative notions of resource, such as traces. However, constructing a usable proof- 
theory for a mixed commutative/non-commutative notion of resource (i.e. heaps and a 
putative non-commutative consumable resource) is hard. Also, the resource acquisition 
variant of the program logic that we describe in the next section requires commutativity. 

3.6. Allowing for Resource Acquisition. The operational semantics and program logic 
described above assume a fixed total amount of resource that may be consumed by the 
program. The precondition of the main procedure of the program specifies the amount of 
resource that will be required for the entire run. In this section we consider the changes 
necessary to support dynamic but fallible acquisition of resources via a special acquire 
instruction. We provide an example use of this additional capability in ISection 3.71 

We assume that there is a capricious environment that entertains requests for additional 
resources from programs. Requests may be granted or denied. A program may request an 
additional resource using a special acquire instruction. To make things interesting, and 
to allow for the example in the Inext section) we make the resource requested by acquire 
dynamic and correspondingly modify consume, removing its static argument: 

i ::= ... I consume | acquire 

For both instructions, we assume that the resource being consumed or requested is indicated 
by an integer value on the stack. For the acquire instruction the intended semantics is that 
if the request is granted then a 1 is pushed on to the operand stack, otherwise a is pushed. 

For the operational semantics, we modify the relation -^^^ to have an additional "ac- 
quired resources" component: 

f 1 H > /, H, T (consumed y ^acquired 

For each of the existing heap mutating instructions except consume, the acquired resource 
is equal to the unit of the resource monoid, e. The operational semantics of consume is 
replaced by the following rule to reflect the dynamic resource identification: 

code[pc] = consume 
{code,z :: S, L, pc}, H {code, S, L, pc + 1), H, res(2;), e 

where we assume the existence of a function res : Z ^ TZ that names certain consumable 
resources in TZ by integers. We do not assume that res is a monoid homomorphism. Two 
new operational semantics rules are added for the acquire instruction, for the two possible 
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outcomes of requesting more resource: 

code[pc] = acquire 



{code, z :: S, L, pc}, H {code, 1 :: S, L, pc + 1), H, e, res(2;) 



code[pc] = acquire 



{code,z :: 5, L, pc}, H {code, :: 5, L, pc + 1), H, e, e 

States of the virtual machine are modified to be four-tuples {rcon:ftot,H,fs) of consumed 
resources, total allowed resources, current heap and current activation frame stack. The 
invariant that is now to be maintctined is that the ?^con 

is always less than or equal to rtot- 



The only rule from Figure 4 that is modified (apart from threading through the unchanged 
rtot) is the rule incorporating -^^^ into the relation: 

f,H^f',H',r,,ra 

<r, rtot,H, f :: fs) ^ {r ■ r^, rtot ■ ra, H', f :: fs) 

The halting predicate is extended to a five-place relation s [ H,rcon,i^tot,v, where rcon is 
the total consumed resource of the execution and rtot is the total acquired resource. 

Perhaps surprisingly, the assertions (pre- and post-conditions and instruction level as- 



sertions) are left unchanged, as are the rules of the logic from Figure 5 for the original set 
of instructions. We modify the rule for resource consumption to take into account the new 
dynamic nature: 

{X(env, args, r, H, S, L). 
Vz, S'. S = z :: S' =^ 3r'. \ =^ i:consume 

res(2;) • r' E r a C\i + l\[env, args, r' , H, S' , L) 

and we add a new rule for resource acquisition: 

r \lz,S'. S = z:: S' ^ 

C \-Q < \{env, args,r, H, S, L). C\i + l\{env, args,r ■ res(z), ff, 1 :: 5', L) ^ ^ z:acquire 
[ A C[i + l]{env, args,r, H,0 :: S' , L) 

This exactly mirrors the pair of operational semantics rules. An acquire instruction is safe to 
run if it is safe the execute the next instruction either with additional available consumable 
resource and a 1 on the stack, or with no additional consumable resource and a on the 
stack. 

The definition of safe frame remains unchanged from above, and the statement of the 
second item of ILemma 3.11 is adjusted to account for the possibility of additional resources 
being acquired: 

Lemma 3.5 (Intra-frame safety preservation (Resource Acquisition Variant)). 
(2) // 

(a) safeFrame ( env , f. Hi, r, args , Q) 

(b) Hii^H2 and Hi w H2 = H 

(c) f,H^f,H',r„ra 

then there exists H[ and r' such that 

(a) H[#H2 and H[wH2 = H' 

(b) rc • r' ^ r ■ ra 

(c) safeFrame (env , f, H'i,r' , args, Q). 
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The definition of the safeStack predicate remains the same as before, and the safeState 
predicate is modified to be of the form safeState{s, env, args, Q): the original r^ax argument 
is taken to be the rtot from the state. The key safety property, as before, is that the consumed 
resources, plus the future resources, is less than or equal to the total allowed resources. But 
now the total resources allowed may be increased during execution. 
The new version of lTheorem 3.31 is as follows: 

Theorem 3.6 (Soundness (Resource Acquisition Variant)). Assume that all the procedures 
in prg match their specifications. 

(1) // 

(a) safeState{s, env, args, Q); and 

(b) s — > s 

then safeState{s' , env, args, Q). 

(2) If safeState{s, env, args,Q) and s [ H, r con, rtot, "v, then there exists an r' such that 
Q{env, args ,H,r',v) and r^on ■ r' E rtot ■ 

This theorem gives a comparable guarantee to [Theorem 3.31 in that the (now dynamic) 
resource bound is respected at every step of the computation and at the end of execution. 
By inspection of the operational semantics, we can see that the resource bound may only 
be increased by successful execution of an acquire instruction. 

3.7. Resource Acquisition Example. To illustrate the utility of the language and logic 
extended with resource acquisition, we take the example of block hooking as presented by 
Aspinall, Maier and Stark The scenario is that an application running on a mobile 
device has a list of telephone numbers that it wants to send SMS messages to. Permission 
must be sought from the user to send these messages, since sending incurs a monetary 
cost. It is not necessarily convenient to request permission from the user when the message 
is to be sent, so permission is requested in advance. We use the program logic extended 
with resource acquisition to bridge the gap between the acquisition of permission and its 
consumption, ensuring that no attempt is made to perform an operation that has not been 
authorised. In this scenario, the acquire instruction is implemented by actually requesting 
permission from the user. 



Figure 6 shows the code for a method, requestPermissions, that loops through a list 
of telephone numbers, requesting permission for each one. We assume that the calls to the 
method acquire are compiled to instances of the acquire instruction. We have taken the 
liberty of assuming a value type of telephone numbers rather than re-using the int type. 
The result of the resource acquisition attempt is stored in the permission field of the record 
for that telephone number. 

The specification of the precondition of requestPermissions is simply that there is a 
proper linked list on the heap, using the following inductively defined predicate: 

t I \ I \ r number -, r permission , p next i i / \\ 

\s&g[x,y) = [x = y A emp) v {^n,p,z. [x nj * [x p\ * [x z\ * lseg(z,yj) 

In the post-condition, we make use of another inductively defined predicate that states the 
resources available, dependent on the value of the permission field: 

lseg'^"''(x,y) = (3; = yAemp) 

V (3n, z. [x ""/H^^'' n] * [x p^'''^^'°" ^ ^send(n) ^ j"^ ^ lseg(2;, y)) 

/-, r number ^ r permission , ^ next -, , , nx 

V (dn, z. \x nj * UJ * [x zj * lseg(2;,yjj 
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class PhoneNumberNode { 

public PhoneNumber number; 
public boolean permission; 
public PhoneNumberNode next; 



public static void requestPermissions (PhoneNumberNode phoneNumber) { 
while (phoneNumber != null) { 

phoneNumber .permission = acquire (phoneNumber .number) ; 
phoneNumber = phoneNumber . next ; 

> 

} 



Figure 6: Resource Acquisition Example 



Thus when the permission field has the value 1, the list node is associated with the 
permission to send to that telephone number; and when the permission field has the value 
0, no such associated permission is available. We revisit this kind of conditionally-resource- 
carrying predicate in [Section 4.2[ 

Re- interpreting the consume instruction as sending an SMS message, a loop that sends 
messages to all telephone numbers that the user has approved now looks much like the 
simple list iteration example from the [introduction! augmented with a dynamic check to 
ensure that permission has been sought and received. 



4. Deep Assertion Logic 



In the previous section we described a program logic but remained agnostic as to the exact 
form of the assertions save that they must be predicates over certain domains. This shallow 
approach makes the statement and soundness proof easier, but inhibits discussion of actual 
specifications and proofs in the logic. In this section we show how a combination of two 
variants of the logic of Bunched Implications (BI) [201 122] can be used to provide a syntax 
for assertions in our program logic. We combine boolean BI with affine intuitionistic BI, 
for describing heaps and consumable resources respectively. 



4.1. Syntax and Semantics. We made use of three different types of lassertioni for the 
program logic: procedure pre- and post-conditions, and intermediate assertions within pro- 
cedures. These all operate on heaps and consumable resources and the arguments to the 
current procedure, but differ in whether they talk about return values or the operand stack 
and local variables. To deal with these differences we assume that we have a set of terms in 
our logic, ranged over by t,ti,t2,.-., that at least includes logical variables and a constant 
null for representing the null reference, and also variables for representing the current proce- 
dure arguments, the return value and the operand stack and local variables as appropriate. 
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Figure 7: Semantics of assertions 



Formulae are built from at least the following constructors: 
::= T I ti M t2 I 01 A 02 I 01 V 02 I 01 ^ 02 I emp I 01 * 02 I 01 ^ 02 I Vx.0 I 3x.0 

\ [tl t2] \ Rr \ ■ ■ ■ 

Where x 6 { = , =1=}. We can also add inductively defined predicates as needed, see lSection 4.21 
below. The only non-standard formula with respect to Separation Logic is Rr which rep- 
resents the presence of some consumable resource r. The semantics of the assertion logic 



is given in Figure 7 as a relation |= between environments and heap/consumable resource 
pairs and formulae. We assume a sensible semantics [J.^ for terms in a given environment. 

As a consequence of having an ordering on consumable resources, and our chosen seman- 
tics of emp, * and — *, our logic contains affine intuitionistic BI as a sub-logic for reasoning 
purely about consumable resources. 

Proposition 4.1. If (p is a propositional BI formula with only Rr as atoms, then r |=t,i 
iffV, {r,h) \= 0. 



4.2. Inductively Defined Shape and Resource Predicates. We now present some 
inductively defined predicates that demonstrate how heap-resident data structures may have 



resources associated with their nodes. We have introduced the resource- aware Iseg predicate 



that describes a segment of a list with a resource associated to every element: 

lseg(r, x,y) = [x = y A emp) v (3d, z. [x d\ * [x "S* z] * R^ * lseg(r, z, y)) 

An alternative that we made use of in the block booking example in [Section 3.71 is to only 
demand resources when the element data satisfies some predicate, for example when the 
integer stored in the node is not equal to zero: 

lseg"'"°(r, x,y) = {x = y A emp) v (id, z. [x d\ * [x "S*^ z] * {d =\= ^ R^) * lseg"'"''(r, z, y)) 

This kind of specification allows the conditional resource property to be specified locally 
within the list structure. If we were attempting explicit resource accounting using sized 



22 



R. ATKEY 



predicates, we would be forced to reflect the whole list into the logic and state the resource 
requirement in terms of the number of non-zero elements: 

\seg{l,x,y) Ar = length(filter(Ax.x =1= 0,/)) 

Reasoning with such global list properties is obviously much harder than locally reasoning 
about each individual node as it is processed by the program. 

The amortised approach is not limited to reasoning purely about singly-linked lists, the 
standard doubly-linked list and tree predicates of Separation Logic can be easily augmented 
with local resource annotations (we have omitted the data components of these predicates 
to save space): 

dlseg(r, p, x,y) = {x = y A emp) v (3z. [x z] * [x h^' p] * ■* dlseg(r, x, z, y)) 
tree(r, z) = (x = null a emp) 

V (3y, z. [x 'h2 y] * [x z] * * tree(y) * tree(z)) 
These predicates all describe resources that are linear in proportion to the sizes of the data 
structures. Using the clever technique of Hoffmann and Hofmann [Ijj, we can also present 
lists with associated resources that are polynomially proportional to the length of the list, 
by exploiting the presentation of polynomials using binomial coefficients. In their system, 
lists are annotated with resources that are lists of rational numbers (pi, The idea 

is that a list of length n annotated with such a list has 2(^1 {l)Pi associated resource. We 
can give such lists as an inductively defined predicate in our logic: 

lseg(^, x,z) = (x = z A emp) v [x "S* y] * R^^ * lseg(<l ("?/), y, z)) 

where <{~J?) = (pi +P2,P2 + Pz-, ■■■■,Pk-i-,Pk) is the additive shift of a resource annotation 
as defined by Hoffmann and Hofmann. 

4.3. Heap and Resource Separation. In the logic of [Section 4.H we only made use of 
one kind of separating conjunction, (pi * (j)2, that separates both heaps and consumable 
resources. This allows the tight integration of the heap shapes of various data structures 
and consumable resources as shown in the [previous section[ Evidently, there are two other 
possible combinations that allow sharing of heap or resources. For example, separation of 
resources, but sharing of heap: 

R 

7/, X 1= 01 * 02 iff X = (H,r) and exists ri,r2. st. 

and ry, {H, ri) |= 0i and i], {H, r2) |= 4>2 

This definition looks like it might be useful to specify that we have a single data structure 
on the heap, but two resource views on it. A need for this kind of situation arose in the 
merge-sort example in [Section 2.2[ There, the auxiliary procedure advance, that advances 
a pointer a certain number of elements through a list, was given the specification: 

Pre(advance) : \5eg{aQ,l, null) 

Post(advance) : lseg(ao, 1, retval) * lseg(ao, retval, nu//) 

where oq was an amount of resource associated with every element of the list that was to be 
preserved. Note that advance does not modify the list in any way and does not consume 
any resources. Evidently, this specification is satisfied for any ag. In the spirit of Separation 
Logic, we would like to be able to state the specification of advance without mentioning 
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resources — because it does not consume or release any — and combine the specification later 
on with the fact that the list has some associated resources. So, we would like to give 
advance the specification: 

Pre(advance) : \seg{0,l, null) 

Post(advance) : lseg(0, 1, retval) * lseg(0, retval, nu//) 

since it does not require or yield any consumable resource, and then apply a putative 
resource- frame rule: 

{P} C {Q} 
{P*R}C {Q * R} 

Where R would record that every element of the unmodified list has oq associated resource. 
As with the normal frame rule of Separation Logic, this turns what would be a second-order 
universally quantified assertion into an unquantified assertion. This simplification is crucial 
for developing automated procedures for discharging verification conditions as in [Section 51 
For the present example, we can use linear programming to infer the instantiation of ao, 
but for general complex composite resources, or for examples that require polymorphic 
recursion, this problem could become much harder. 

Unfortunately, in order for this rule to be sound we must ensure that C does not modify 
the heap in any way that would violate the resource associations. There is currently no 
way to enforce this within the logic. In the example, this manifests itself as the inability to 
guarantee that the list in the post-condition of advance has exactly the same shape as the 
list in the precondition, which would be required to assign a resource to every element. 

5. Automated Verification 

In this section we describe a verification condition (VC) generation and proof search proce- 
dure for automated verification of programs against specifications in the program logic, as 
long as procedures have been annotated with loop invariants. The restricted subset of Sep- 
aration Logic that we use in this section is similar to the subset used by Berdine et al. [6], 
though instead of performing a forwards analysis of the program, we generate verification 
conditions by backwards analysis and then attempt to solve them using proof search. We 
develop our own proof search procedure rather than re-use an existing Separation Logic- 
inspired tool in order to incorporate a key feature of Hofmann and Jost's amortised system: 
the use of linear programming to infer resource annotations [15j . In the system we present 
here, the proof search procedure generates linear constraints that can be solved by linear 
programming to infer resource annotations. A limitation of the VC-generate and solve tech- 
nique we use here is the potential for exponential blow-up of the verification conditions in 
the size of program. The forward symbolic execution approach deals with this by attempt- 
ing to prune unreachable paths as soon as possible and merging similar feasible paths using 
heuristics. 

5.1. Restricted Assertion Logic. Following Berdine et al., we make use of a highly re- 
stricted assertion logic that forbids arbitrary nesting of the additive and separating conjunc- 
tions and disallows negative occurrences of implications. This makes proof search practical. 
For the purposes of resource annotation inference, consumable resources are represented in 
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the restricted syntax as linear expressions over a collection of globally existentially quanti- 
fied meta- variables. We use yi,y2, and so on for resource variables to be inferred, and xi,X2, 
etc. for logical variables. Resource variables cannot be quantified over inside formulae. 
The basic assertion of the proof search logic is of the form 

\/3x. n, I I Qi 

i 

where we use the meta- variable S to stand for such assertions. They consist of a finite 
disjunction of clauses, each with a collection of existentially quantified variables and three 
collections of assertions. The first portion, 11, contains assertions about pure (non-heap and 
non-consumable resource) data, which are equalities and disequalities of the form: 

P ::= = t2 I ti + t2 

The terms that we allow in the data and heap assertions are either variables, or the constant 
null. A collection 11 = Pi, is interpreted by translation into the logic of lSection 41 as 

the additive conjunction of the Pi. The second portion, E, contains assertions about the 
heap, which are of the form: 

X ::= [h^t2] I Iseg(e,ti,t2) 

Here we have made use of the inductively defined list segment predicate from [Section 4.21 
A collection S = Xi, ...,Xn is interpreted as the separating (or multiplicative) conjunction 
of the Xi. The final portion is a linear expression indicating an amount of consumable 
resource. It is easily possible to generalise this to multiple resources by considering multiple 
named linear expressions. Given a valuation of the resource meta- variables t/i, extended to 
an interpretation [[©J this is interpreted in the logic of [Section 41 as the formula i?!®!'' for 
some fixed resource r. A whole composite 11 | S | G is interpreted as 11 a (S * R^^^^). 

Finally, we have the set of goal formulae that the verification condition generator will 
produce and the proof search will solve. 

G ::= S*G\S^G\S\GiAG2\P^G\\fx.G\3x.G 

Note that we only allow implications (^ and — *) to appear in positive positions. This 
means that we can interpret them in our proof search as adding extra information to the 
context. 



5.2. Verification Condition Generation. Verification condition generation is performed 
for each procedure individually by computing weakest liberal preconditions for each instruc- 
tion, working backwards from the last instruction in the method. To resolve loops, we 
require that the targets of all backwards jumps have been annotated with loop invariants 



S that are of the special form in the previous section This assumes that the instructions 



have been sorted into reverse post-order so we can scan the instructions in reverse order 
to collect the verification conditions. We omit the rules that we use for weakest liberal 
precondition generation since they are very similar to the rules for the shallowly embedded 
logic in [Figure 5| The verification condition generator will always produce a VC for the 
entailment of the computed weakest liberal precondition of the first instruction from the 
procedure's precondition, plus a VC for each annotated instruction, being the entailment 
between the annotation and the computed weakest liberal precondition. All VCs will have 
a formula of the form S as the antecedent and a goal formula G as the conclusion. 
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The verification condition generation procedure has been formahsed within the Coq 
proof assistant and proved sound with respect to the program logic in [Section "31 By using 
Coq's module system [12] we have abstracted the verification condition generator over the 
particular deep assertion logic used. We used Coq's program extraction capabilities to 
extract the verification condition generator and instantiated it with the proof search logic 
described in this section. 



5.3. Proof Search. The output of the verification condition generation phase is a collection 
of problems of the form S \- G, which can each be reduced to a finite collection of sequents 
of the form 11 | S | |- C To discharge these proof obligations, we make use of the 
I/O interpretation of proof search as defined for intuitionistic linear logic by Cervesato, 
Hodas and Pfenning [9J, along with heuristic rules for unfolding the inductive list segment 
predicate. We augment the I/O model of resource accounting with an additional part 
that collects linear constraints that may be fed into a integer linear program solver, to 
automatically infer resource annotations. 

We use the following judgement form for proof search goals that collect linear con- 
straints. Here C is a set of linear constraints over the resource met a- variables yi: 

n I s I e h G\c 



The proof search procedure is defined by the rules shown in Figure 8 , Figure 9 Figure 10 
and Figure 11 These rules make use of several auxiliary judgements: 

n I S I O h T,goai\'^out,'dout,C Heap assertion matching 
G> \- Q goal \& out, C Resource matching 

H h -L Contradiction spotting 

n h n' Data assertion entailment 

The backslash notation used in these judgements follows Cervesato et al., where in the 
judgement G h Qgoai\&out,C, the proof context G denotes the facts used as input and 
Gout denotes the facts that are left over (the output) from proving Qgoai- The C component 
collects the linear constraints that must hold for the judgement to give a valid separation 
logic entailment. A similar interpretation is used for the heap assertion matching judgement. 
We do not define the data entailment or contradiction spotting judgement explicitly here; 
we intend that these judgements satisfy the basic axioms of equalities and disequalities. 

The rules in [Figure 8] are the goal driven search rules. There is an individual rule 
for each possible kind of goal formula. The first two rules are matching rules that match 
a formula S against the context, altering the context to remove the heap and resource 
assertions that S requires, as dictated by the semantics of the assertion logic. We must 
search for a disjunct i that is satisfied by the current context. There may be multiple such 
i, and in this case the search may have to backtrack. When the goal is a formula S", then 
we ask that the left-over heap is empty, in order to detect memory leaks. Note that the 
logical variables a^i, X2, ... may not occur in the constraint sets, so we do not need to handle 
universally quantified constraints. 

The matching rules make use of the heap and resource matching judgements defined 
in Figure 9 The heap matching judgements take a data, heap and resource context and 
attempt to match a list of heap assertions against them, returning the left over heap, 
resources and computed constraints. The first three rules are straightforward: the empty 
heap assertion is always matchable, points-to relations are looked up in the context directly 
and pairs of heap assertions are split, threading the contexts through. For the list segment 
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exists n I S I e I- Sip/x]\S',e',CH 

n h Ui\i/x] Q' h 9i[t/rc] \ Cr u\j:' \e" hG\CG 
n I s I e h (y^^- I Si I *g\ 

exists n I S I e I- Sip/x]\emp,e',CH H h 6' h 6^ \ 9", Ci? 

n I E I e h \/3x. n, I Ei I bach uC^ 

i 

foralH,x. H, | S, E^ | 6 + h G\C 



n I s I e h (^Y^^- ^^ I I e^j 



n,p 




e h G\c 


n 


s 





n|s|ehGi\Ci n|s|GhG2\C2 n|E|ehG\c x^/w(n)u^(s) 

n I S I G h Gi A G2\Ci uC2 n I S I G h Vx.G\C 

n I S I G h G[t/x]\C 
n I S I G h 3x.G\C 

Figure 8: Goal Driven Search Rules 

rules, there are three cases. Either the two pointers involved in the list are equal, in which 
case we are immediately done; or we have a single list cell in the context that matches the 
start pointer of the predicate we are trying to satisfy, and we have the required resources 
for an element of this list, so we can reduce the goal by one step; or we have a whole list 
segment in the context and we can reduce the goal accordingly. The resource matching 
rule is where linear constraints are actually generated; to match a resource we subtract the 
desired resource from the available resources and add a constraint to ensure that there was 
enough resource to do this. Note that this rule always succeeds during proof search, but 
may generate unsatisfiable constraints. Thus back-tracking may still be required. 

The final two sets of rules operate on the proof search context. The first set, shown 
in Figure 10 , describe how information flows from the heap part of the context to the data 
part. If we know that two variables both have a points-to relation involving a field f , then 
we know that these locations must not be equal. Similarly, if we know that a variable does 
point to something, then it cannot be null. If any contradictions are found using these rules, 
then the proof search can terminate immediately for the current goal. This is provided for 



by the first rule in Figure W\ 



The final set of rules performs heuristic unfolding of the inductive Iseg predicate. These 
rules are shown in [Figure 11 [ These rules take information from the data context and use 
it to unfold Iseg predicates that occur in the heap context. The first rule is triggered when 
the proof search learns that there is a list segment where the head pointer of the list is 
not equal to null. In this case, two proof search goals are produced, one for the case that 
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Heap Matching Rules: 

U\-ti=t[ U\-t2=t'2 

n I s I e h emp\s,e,{} u\^,[ti^t2]\@h[t[^t'2]\^,e,{} 

n I s I e h Si\s',e',Ci n | s' | e' h S2\s",e",C2 
n I s I G h Si * S2\s",e",Ci uC2 

U\-ti=t2 

n|S|ehlseg(Gi,ii,f2)\S,G,{} 

Uhh=t[ e\-ei\e',CR n | s | l5eg(e^,t„,t2)\s^e^Cff 

n I S, [ti "S* tn], [h td] I e h \seg{Qi,t[,t2)\J:',Q",CR u c^^ 

n h = ti n I S I 9 h lseg(9^,^2,t3)\S^9^C 
n I S,lseg(9,,ti,t2) I e h lseg(9^t;,t3)\5]',9',C 

Resource Matching Rule: 



9 h 9'\(9 - 9'), {9 ^ 9'} 
Figure 9: Matching Rules 



n h 1 



n|S|9hG\{} 

S = [ti ^t],[t2 n,ti +t2 I s I 9 h G\C 

n I S I 9 h G\C 

S = [th^t'],E' U,t^null\T,\ehG\C 
n I S I 9 h G\C 

Figure 10: Contradiction Flushing 

the list segment is empty and one for when it is not. The other rules are similar; taking 
information from the data context and using it to refine the heap context. 

The proof search strategy that we employ works by first saturating the context by 
repeatedly applying the rules in Figure 10] and [Figure ll| to move information from the data 



context into the heap context and vice versa. This process terminates because there are a 
finite number of points-to relations and list segment predicates to generate rule applications, 
and when new predicates are introduced via list segment unfolding they either do not trigger 
any new inequalities or are over fresh variables about which nothing is yet known. Once 
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n h ti + null 

n,ti = t2 I S I e h G\Ci n | SJti "^^'xHh "^A" y],\seg(R,x,t2) \e,Rh G\C2 

n I E,lseg(i?,ti,t2) I e h G\Ci uCs 

Uhti = null U,t2 = null \Y. \e h G\C U \- h = t2 H | S | 9 h G\C 
n I S,lseg(i?,ti,t2) I e h G\C n | E,lseg(i?,ti,t2) I h G\C 

n h ti + t2 n I "^^'xjjti 1gi'y],l5eg(ig,x,t2) I 0,i? h G\C 

n I s,iseg(ii,ti,t2) I e h G\C 

Figure 11: List Unfolding Rules 

the context is fully saturated, the proof search reduces the goal by using the goal-driven 
search rules and the process begins again. 

Given a collection of verification conditions and a successful proof search over them 
that has generated a set of linear constraints, we input these into a linear solver, along with 
the constraint that every variable is positive and an objective function that attempts to 
minimise variables appearing in the precondition. 

Theorem 5.1. The proof search procedure is terminating. Moreover, it is sound: i/II | S | 
Q \- G\C and there is an valuation of the y that satisfies C, then 11 a (S |- G under 

this valuation using the translation of the proof search logic into the logic of \Section 4 as 
defined in \Section 5.11 



6. Examples of Automated Verification 
6.1. Small Examples. We have tested the automated resource inference procedure de- 



scribed in the [previous section on several small examples, including the simple loop itera- 



tion example from the lintroductioni and the examples from [Section "21 We summarise these 



examples in the following table. Note that the proof search procedure also verifies the mem- 
ory safety of these examples. For timings, these tests were performed on an PC running 
64-bit Ubuntu Linux 10.10 on an 8-core Intel Core 17 860 at 2. 80GHz. Times were measured 
using the GNU time utility. Our implementation only makes use of a single core. 
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Name 


Property Inferred 


Time (s) 


iterate_list 


Number of iterations is length of input list 


0.010 


iterate_recursive 


Number of calls is length of input list 


0.010 


copy_list 


Number of allocations is length of input list 


0.013 


reverse 


Number of iterations is length of input list 


0.012 


queue 


Resource annotations on enqueue and deqeueue 


0.019 


f rying_pan 


Number of times each element is visited 


0.018 


mergesort 


Number of comparisons is length of input list 


0.037 


tree_traverse 


Number of calls is size of input tree 


0.012 


tree_copy 


Number of allocations is size of input tree 


0.014 


tree_mirror 


Number of calls is size of input tree 


0.012 



In each of these examples, we seeded the program with loop invariants describing the 
shape of heap data structures, but left our implementation to infer the resource bounds. The 
last three examples involving trees make use of the inductive tree predicate from lSection 4.2l 
The proof search procedure was augmented with heuristic rules for matching and unfolding 
instances of the tree predicate, following those for lists. The tree examples are all recursive 
procedures. 

As can be seen from the table, the time taken for each of the examples is trivial. It 
remains to be seen how well this technique scales to real-world code. It seems evident 
that the VC-generate and solve process is not scalable in general due to the potential for 
exponential blow-up in the size of the generated formulae. A more realistic implementation 
of the program logic described in this paper would likely use the forward symbolic execution 
approach, as described by Berdine et al. (6j. 



6.2. Prying Pan List Reversal. As a larger example, we demonstrate the use of the proof 
search procedure coupled with linear constraint generation on the standard imperative in- 
place list reversal algorithm on lists with cyclic tails (also known as "frying pan" lists). This 
example was used by Brotherston, Bornat and Calcagno [7] to illustrate the use of cyclic 
proofs to prove program termination. Here we show how our amortised resource logic can 
be used to infer bounds on the time complexity of this procedure. 













f 























The "handle" of the structure consists of the nodes a, b, c and the "pan" consists of the 
nodes d, e and f . When the in-place list-reversal procedure is run upon a structure of this 
shape, it will proceed up the handle, reversing it, around the pan, reversing it, and then 
back down the handle, restoring it to its original order. For the purposes of this example, we 
assume that it takes one element of resource to handle the reversal of one node. Following 
Brotherston, Bornat and Calcagno, we can specify a cyclic list in Separation Logic by the 
following formula, where vq points to the head of the list and vi points to the join between 
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the handle and the par0. 

3/c.lseg(xi, Wo, vi) * [vi k] * Iseg(x2, k, vi) * R^^ 

We have annotated the list segments involved with resource annotation variables xi and X2 
that we will instantiate using linear programming. The predicate R^^ denotes any extra 
resource we may require. Similarly, we have annotated the required loop invariant (adapted 
from Brotherston et al.): 

{3k. Iseg(ai, /o, ''^i) * Iseg(a2, h, null) * [vi "S* k] * Iseg(a3, k, vi) * R""^) 

V {3k. \seg{bi,k,nuU) * [j "S* k] * \seg{b2,lo,vi) * lseg(63, * R^^) 

V {3k. Iseg(ci, /q, null) * Iseg(c2, /i, vi) * [vi k] * Iseg(c3, k,vi) * R^*) 

Each disjunct of the loop invariant corresponds to a different phase of the procedure's 
progress. Brotherston et al. note that it is possible to infer the shape part of this loop 
invariant using current Separation Logic tools. Here, we have added the ability to infer 
resource annotations, and hence bounds on the time consumption of the procedure. Running 
our tool on this example produces the following instantiation of the variables: 



Precondition 






Xi 


= 2 


X2 


= 1 


X?. 


= 2 






Loop invariant. 


phase 


1 




= 2 


02 


= 1 


as 


= 1 


a4 


= 2 


Loop invariant. 


phase 


2 


bi 


= 1 


b2 


= 1 




= 




= 1 


Loop invariant. 


phase 


3 


Cl 


= 1 


C2 


= 


C3 


= 


C4 


= 


Post-condition 






x'l 


= 


X2 


= 




= 







Pictorially, the inference has associated the following amount of resource with each part of 
the input structure: 




1 

Each node of the handle has 2 associated elements of resource, to handle the two passes 
of the handle that the procedure takes, while the pan has one element of resource for each 
node. The inferred annotations for the loop invariant track how the resources on each node 
are consumed by the procedure, gradually all reducing to zero. Since we have added a 
consume instruction to be executed every time the procedure starts a loop, the resource 
inference process has also verified the termination of this procedure, and given us a bound 
on the number of times the loop will execute in terms of the shape of the input. 



7. Conclusions 

We have presented a program logic that extends the resource reasoning capabilities of Sep- 
aration Logic from reasoning about mutable resources such as the heap to consumable 
resources such as time. We have demonstrated how doing so allows tight connections be- 
tween the shape of data structures and the resources required to process them to be stated, 

^Note that the data part of the hst node has been omitted in this formula and in the loop invariants to 
reduce clutter. 
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and so expanding the reach of Separation Logic's local reasoning principle to consumable 
resources. 

We have presented an automated proof procedure that takes programs annotated with 
shape invariants and infers consumable resource annotations. The main limitation of this 
automated proof search procedure is that it only supports the statement and inference of 
bounds that are linear in the size of lists that are mentioned in a procedure's precondition. 
This is a limitation shared with the original work of Hofmann and Jost [T5] . We note that 
this is not a limitation of the program logic that we have presented, only of the automated 
verification procedure that we have layered on top. In lSection 4.2l we presented a Separation 
Logic version of the polynomial potential lists of Hoffmann and Hofmann [Ijj, which opens 
the way to inference of polynomial bounds for pointer manipulating list programs. Initial 
experiments with extending our implementation in this direction have been promising. 

We have demonstrated that the use of mixed shape and resource assertions can sim- 
plify the complexity of specifications that talk about resources, and this should extend to 
extensions of the proof search procedure, or to interactive systems based on this program 
logic. The resource aware program logic of Aspinall et al. [3j also uses the same layering: 
a general program logic for resources (which is proved complete in their case) is used as a 
base for a specialised logic for reasoning about the output of the Hofmann-Jost system. 

A possible direction for future work is to consider different assertion logics and their 
expressiveness in terms of the magnitude of resources they can express. We conjecture that 
the deep assertion logic we have presented here, extended with the Iseg predicate can express 
resources linear in the size of the heap. It would be interesting to consider more expressive 
logics and evaluate them from the point of view of implicit computational complexity; the 
amount of resource that one can express in an assertion dictates the amount of resource 
that is available for the future execution of the program. 

Additional future work is to consider the proof theory of the combined Boolean BI and 
affine intuitionistic BI that have used in this paper. 

Other resource inference procedures that are able to deal with non-linear bounds include 
those of Chin et al. [lOl [H], Albert et al. [I] and Gulwani et al. [13]. When dealing 
with heap-based data structures, all of these techniques use a method of attaching size 
information to assertions about data structures. As we demonstrated in lSection 2.1\ this can 
lead to unwanted additional complexity in specifications. However, all of these techniques 
deal with numerically bounded loops, which our current prototype automated procedure 
cannot. We are currently investigating how to extend our approach to deal with non-linear 
and numerically-driven resource bounds. 
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